Many client applications and operating system programs use a transactional model to insure the consistency of a dataset in data storage. Changes to the dataset are captured in transactions. Each transaction is performed in such a way that in the event of a system failure, it is possible to complete all of the changes of the transaction so that the dataset is restored to a consistent state.
For example, a single transaction in an accounting application transfers a certain amount of money from a first account to a second account. This transaction debits the first account by the certain amount and credits the second account by the same amount. If a system failure occurs during the transfer, the dataset of the accounts can be left in an inconsistent state in which the accounts do not balance because the sum of the money in the two accounts has changed by the certain amount. In this case, the transactional model permits a recovery program to restore the dataset to a consistent state upon re-boot of the system after the system failure.
Operating system programs such as file system managers and database managers typically use the transactional model to restore a file system or a database to a consistent state upon reboot of a data processor after a system failure. In the case of a server, transaction logging is the preferred method of using the transaction model. Transaction logging involves writing a record for each transaction to a transaction log in data storage before the writing of the changes of the transaction to the dataset in data storage, so that the transaction log can be used to restore the dataset to a consistent state after a system failure.
For example, a client application sends a transaction request to an operating system program, and the operating system program responds by writing a corresponding transaction record to the transaction log, and then returning an acknowledgement of completion of the transaction to the client application, and then beginning a task of writing the changes of the transaction to the dataset in storage. In this fashion, the use of the transaction log permits the processing of a next transaction to begin before the changes of a previous transaction are written to the dataset in storage. Latency of responding to the transaction request is reduced by writing the transaction record to the transaction log in data storage faster than the corresponding changes can be written to the dataset in data storage.
Upon reboot of the data processor after a system failure, the transaction log may include many records of transactions not-yet-completed by the time of the reboot. In this case, a recovery program replays all of these not-yet-completed transactions so that all of the changes of the not-yet-completed transactions are applied to the dataset. In this fashion, the dataset is restored to the consistent state requested by the last transaction request that was acknowledged as completed. Further details of the logging and replay process are described in Uresh Vahalia et al., Metadata Logging in an NFS Server, USENIX 1995, Jan. 16-20, 1995, New Orleans, La., 12 pages, the USENIX Association, Berkeley, Calif.